I. Magnum V 测试程序架构简介
A. Magnum V 测试系统概述
Teradyne Magnum V 是一款专为闪存（Flash）、动态随机存取存储器（DRAM）及多芯片封装（MCP）市场设计的新一代存储器测试解决方案 1。该系统以其高引脚数、高被测器件（DUT）并行度、高频率以及可扩展平台为主要特性，旨在降低测试成本并提高测试效率。
B. Magnum V 测试系统的配置
Teradyne Magnum V 主要有Magnum V EV, Magnum V SSV, Magnum V GV 三种，且允许测试程序在EV工程版本上开发后，无缝应用于生产系统，这意味着其核心文件结构的高度共通性。
· Magnum V EV(Engineer Vehicle): 用于测试程序工程版开发和调试;
· Magnum V SSV(Super Site Volume) : 适用于量产最终测试(FT)，其WS(Wafer Sort)配置可支持量产晶圆测试(CP)；·
· Magnum V GV(Grand Volume): 主要用于FT, 侧重于超大规模并行测试 2。
C. Magnum V 软件环境与理念
Magnum V 的软件架构核心是“基于 DUT 的多站点(Site)架构” 2。测试工程师只需为单个器件编写测试程序，系统硬件和软件便会自动将测试克隆到多个测试站点并行执行 2。这一理念极大地简化了并行测试程序的开发。Magnum V 的主机通常配置为 Windows 服务器环境，并使用 Visual Studio作为开发环境。
II. Magnum V 测试程序核心文件及其分类
Magnum V 测试程序的根本目标是根据器件的规格书验证其功能和性能，并最终对器件进行分级（binning）。一个完整的测试程序是由多种不同类型的文件协同工作构成的集合。这些文件通常包括用于定义测试逻辑的源代码文件、用于设定测试参数的配置文件、用于提供激励信号的pattern文件等。为了更清晰的理解程序架构，下面将 Magnum V 测试程序中主要的文件分为以下几类：
· 测试流程与执行控制文件: 定义了测试程序的主要操作序列、测试执行逻辑、及整体控制流程；
· 器件与测试配置文件：用于定义被测器件（DUT）的特定参数以及详细的测试条件，包括Pin Setting, 时序设置等；
· 测试Pattern文件：包含了施加到 DUT 的激励信号和预期的响应数据，是功能测试的核心；
· 源代码、库与头文件： 包含由用户定义的基于C++的代码用于实现测试流程和由 Teradyne 提供的用于控制机台硬件和系统的API和编译库；
· 数据管理与分析文件：包含冗余分析(RA)，分Bin, 测试数据处理等；
· 校准与系统接口文件：测试机与DUT 之间的物理接口配置及测试通道校准数据等；
· 输出、日志与报告文件： 记录测试过程中的关键信息及将测试结果按格式生成测试结果文档；
A. 测试流程与执行控制文件
功能： 这类文件定义了测试程序的主要操作序列、测试执行逻辑、条件分支以及整体控制流程。它们负责协调对各种测试模块的调用、仪器设置以及数据记录例程。主要由 C++ 源文件（例如 .cpp, .cc, .cxx）和头文件（.h, .hpp）组成。这些 C++ 源文件经过编译和链接生成可执行测试程序(.exe)，该程序能够在 Magnum 操作系统下的每个测试站点(Site)的多核CPU上运行。它们与系统库紧密交互，以实现对测试机硬件的控制。
· host_begin.cpp: 可查阅Manual，见主机开始块（Host Begin Block）
· site_begin.cpp: 见站点开始块（Site Begin Block）
· seq_and_bin.cpp: 见序列与分箱表（Sequence & Binning Table）
· test_blocks.cpp: 见测试块（Test Blocks）
Note: Visual Studio 的使用不仅意味着 C++ 是主要的编程语言，还意味着测试程序的开发环境将包含 Visual Studio 特定的项目文件（例如，用于解决方案的 .sln 文件，用于项目的 .vcxproj 文件）。这些项目文件负责管理编译和链接过程，是构建可执行测试程序的关键组成部分。
B. 待测器件与测试配置文件
这些文件用于定义被测器件（DUT）的特定参数以及详细的测试条件。主要有以下几类：
1. 引脚配置文件 (Pin List & Pin Assignment)
定义测试程序中使用的逻辑引脚以及引脚组的名称以及测试机资源连接到 DUT 的物理测试机通道之间的映射关系。此外，它们还可能定义引脚组，以便于对一组引脚进行统一操作。
· pin_lists.cpp/.h：引脚列表代码及声明，tester.h引用pin_lists.h。
· pin_assignments.cpp：DUT引脚映射，见引脚分配表（Pin Assignment Table），作用是将机台的测试资源分配给DUT 引脚。
2.引脚加扰文件/定义 (Pin Scrambling)
定义逻辑地址或数据位到物理引脚的加扰方式，这通常特定于某一 DUT 或其封装设计，作用是将机台产生的信号分配给DUT 引脚。
· pin_scramble.cpp：见引脚加扰函数与宏（Pin Scramble Functions & Macros）
3. 时序设置文件 (Timing Setup)
定义测试周期的时序参数，例如周期长度、各种信号（时钟、选通、数据）的边沿位置以及信号格式。定义时序集（timing sets），包含周期（TCLK）、驱动边沿（T0, T1）、数据建立/保持时间等参数值。
· TestTimer.h: TEST_TIMER类声明，tester.h引用
· timing_lists.cpp: 时序设置示例，函数在protos.h中声明
4. 电平设置文件 (Level Set)
定义 DUT 引脚的直流电压和电流电平，包含一系列命名的电平规范集，为不同的测试条件将特定的电压/电流值分配给引脚组或单个引脚。例如输入高电平（VIH）、输入低电平（VIL）、输出高电平（VOH）、输出低电平（VOL）、输出高电流（IOH）、输出低电流（IOL）以及参考电压（VREF）。
5. 器件电源供应 (DPS) 配置文件
配置 DUT 的电源供应，包含所用 DPS 通道的设置、电压/电流限值、拉升速率(Slew Rate)、上电/掉电顺序以及保护限值等。
C. 测试图形与向量文件(Pattern)
包含了施加到 DUT 的激励信号和预期的响应数据，是功能测试的核心。
1. 算法图形发生器 (APG) 文件
定义APG 的指令序列。 APG 能够动态生成复杂的存储器测试图形（例如 March、Checkerboard等），包括地址生成指令、数据生成指令以及图形内部的控制流指令（如循环、分支），这对于存储器Array这种高度重复，但数量极大的结构测试至关重要。
2. 逻辑向量文件 (LVM/SVM)
存储预定义的数字测试向量（激励、预期数据、屏蔽位），包含多行向量数据，每行代表一个测试周期，每个周期内对引脚状态进行设置，用于测试器件的逻辑部分或执行特定的重复度不高的非算法序列。
3. 地址拓扑文件 (加扰/映射)
定义APG/测试程序使用的逻辑地址与 DUT 物理存储器组织（例如，行/列加扰、Bank 交错）之间的映射关系。
· address_topo.cpp：配置地址/ECR拓扑逻辑代码，见APG地址/数据配置。
4. 数据缓冲存储器 (DBM) 相关文件/配置
用于定义数据或将数据加载到数据缓冲存储器的文件。DBM 可用于多种目的，如存储大块数据以供 DUT 编程、存储预期数据以供比较，或存储捕获的数据。
D. 源代码、库与头文件 (用户及系统)
1. 用户定义源文件 (.cpp, .h)
包含由测试工程师编写的自定义 C++ 代码，用于实现测试流程、APG 未覆盖的特定测试算法、仪器控制序列、数据处理以及用户界面交互。
2. 系统提供的库文件 (.lib, .dll on Windows, 或等效文件)
由Teradyne提供的预编译库，它们提供了用于控制 Magnum V 测试机硬件（引脚、PMU、DPS、APG、时序等）和访问系统服务的应用程序编程接口 (API)。
3. 系统提供的头文件 (.h, .hpp)
为系统库定义结构、常量、函数原型和类定义。这些头文件被包含在用户源文件中，以便能够针对系统 API 进行编译。
Note：Magnum V 复杂的“基于Site的架构”包含每个Site独立的 CPU 和资源 ，如果直接对 ATE 的硬件寄存器进行编程对于测试工程师而言将是极其复杂且容易出错的。为了提供一个易于管理的编程环境，ATE 制造商通常会提供一个软件层（驱动程序、API、库）来抽象这些硬件细节，测试工程师并非在裸机级别编写代码，而是编写调用这些API的C++代码。
E. 数据管理与分析文件
1. 冗余分析 (RA) 配置文件与数据文件
用于配置冗余分析算法（例如，用于修复带有冗余单元的存储器件）的文件，并存储与 RA 相关的数据或结果。
2. Binning 定义与控制文件
根据测试结果定义将 DUT 分配到不同等级（bin）（例如，好品、坏品、特定故障模式、性能等级）的标准。
3. Datalog 文件
存储详细的测试结果，可能是基于文本的（例如 CSV、类 STDF 格式）或二进制格式，包括测试名称、DUT 标识符、测量值、上下限以及通过/失败标志参数测量值以及潜在的故障诊断信息。
F. 校准与系统接口文件
1. DSA (Device Specific Application) 板相关文件
包含特定于 DSA 板（也称为 DIB - Device Interface Board 或 Load Board，即器件接口板或负载板）信息的文件。DSA 板提供了测试机和 DUT 之间的物理接口。这些文件可能包含特定的布线信息、组件信息或标识信息。
2. TCALDX (校准) 文件/表
存储测试机通道的校准数据，以确保精确的时序和直流参数测量。包含数字 I/O、DC/HV 引脚和 DUT 电源的校正因子、偏移量和时序去偏移值。
G. 输出、日志与报告文件 (由测试程序生成)
1. 测试结果日志
可读性较高的文本日志，详细记录执行流程、主要测试步骤、通过/失败摘要以及错误消息。
2. Wafer Map 文件 (用于晶圆分选)
如果用于晶圆分选（Magnum V SSV WS 配置），则会生成或更新文件，以显示晶圆上每个芯片的通过/失败状态。
III. 测试程序文件的相互依赖与工作流程
Magnum V 测试程序的各个文件并非孤立存在，它们在开发、加载和执行过程中紧密协作，形成一个完整的工作流程。
A. 编译与链接阶段 (开发环境 - Visual Studio)
测试程序的开发始于编写 C++ 源代码文件（.cpp）。这些文件会包含（#include）系统提供的头文件（.h）以及用户自定义的头文件，以访问所需的函数声明、数据结构和常量定义。Visual Studio 项目文件（例如 .vcxproj）扮演着构建指挥官的角色，它管理着编译器和链接器的设置，指定哪些源文件需要编译，哪些库文件需要链接 5。
编译器首先将每个 C++ 源文件转换为中间的目标文件（通常是 .obj 文件）。随后，链接器将这些目标文件与系统提供的库文件（.lib）以及其他用户库捆绑在一起，最终生成一个可执行的测试程序文件（在 Windows 环境下可能是 .exe 文件。
B. 测试程序加载与初始化阶段 (测试机环境)
编译链接完成后，生成的可执行测试程序(.exe)被加载到 Magnum V 的主机控制器，并根据需要分发到各个测试站点的独立多核 CPU 上 1。一旦加载，测试程序便开始其初始化序列：
· 加载引脚配置： 程序首先读取引脚配置文件（Pin Map），建立测试程序中使用的逻辑引脚名称与测试机物理通道之间的映射关系。
· 加载时序与电平设置： 时序设置文件和电平设置文件被加载，用于配置测试机的时序发生器和引脚电子单元（PE），为后续的测试信号生成和施加做好准备。
· 加载 DPS 配置： 器件电源供应（DPS）的配置文件被读取，以设定 DUT 所需的各个电源轨的电压、电流限值以及上电顺序。
· 加载校准数据： 系统会加载 TCALDX 校准表 2 和特定于当前 DSA（Device Specific Application）板的信息 2。这些数据用于补偿测试机硬件的固有误差，确保测试的精度和一致性。
· 初始化 APG： 算法图形发生器（APG）会根据加载的 APG 图形文件和地址拓扑文件进行初始化，准备生成复杂的存储器测试图形。
C. 测试执行阶段
初始化完成后，测试程序的主控制流程（通常由 C++ 代码实现）开始按顺序执行。
· 测试流程会调用各种函数来执行具体的测试项。这包括通过 APG 或 LVM（逻辑向量存储器）向 DUT 施加测试图形和向量。
· 在执行DC测试时，程序会控制参数测量单元（PMU）对 DUT 的电压或电流进行精确测量。
· 每次测试前，系统会参考已加载的时序和电平配置文件，为当前测试项设置正确的测试条件。
· 测试过程中产生的数据，如通过/失败状态、测量值等，会被实时或批量地记录到数据记录文件（Datalog）中。
· 每个测试项完成后，其结果会与 Binning 定义文件中设定的标准进行比较，以初步判断 DUT 所属的等级。
D. 数据输出与报告
测试执行完毕或达到预设的批次结束条件后，测试程序会进行数据汇总和报告生成。
· 完整的数据记录文件（Datalogs）被保存，其中包含了该批次或单个 DUT 的所有详细测试数据。
· 在晶圆分选应用中，会生成或更新晶圆图（Wafer Map）文件，标记出晶圆上每个芯片的测试结果。
结语
C++语言本身鼓励模块化编程。Magnum系统中的一些概念，如 MULTI_DUT_CALL_BLOCK()(允许多个DUT 调用一个测试块)和“测试Bin 函数” （将分级逻辑封装为函数），都体现了将复杂的测试任务分解为更小、更易于管理单元的设计思想。复杂的存储器测试程序如果采用单体式结构，会变得非常庞大且难以维护。Magnum的软件架构支持并鼓励这种模块化方法，允许测试计划由更小、可重用的“测试块”或函数构建而成。因此，一个典型的 Magnum V 测试程序不太可能是一个庞大的单一源文件，而更可能是一个由多
个 .cpp 和 .h 文件组成的集合，每个文件专注于特定的功能（例如，一个文件负责接触测试，另一个文件负责特定的存储器算法测试，还有一个文件负责特性化例程）。配置文件同样也会趋向模块化（例如，引脚图、时序集、电平集分别使用独立的文件）。这种模块化设计显著提高了测试程序的可维护性、可重用性，并促进了团队协作开发。
|
